How Guard Blocks an Architectural Regression

Guard protects the architecture your project has accepted. It observes the repository first, proposes evidence-based rules, and checks later changes against those rules. It learns the project's conventions instead of imposing a universal folder structure.

The regression example

Suppose a dashboard client component imports the database client directly. It may work locally, but it crosses a server/client boundary and bypasses the project's action or service layer. A reviewed Guard rule can flag that import when the file changes.

Establish the project policy

Run this once from the project root:

npx @codapult/cli guard init
npx @codapult/cli guard propose

Inspect the proposals. Approve only rules that describe an intentional project boundary. The exact rule IDs and findings come from the current repository, so do not copy an old fingerprint into another project.

Check a change

After the feature is edited:

npx @codapult/cli guard check --changed

For a complete verification gate:

npx @codapult/cli guard verify --json

Guard reports the changed file, the violated rule or contract, evidence, and the next action. Fix the boundary violation or record a deliberate, owner-attributed, time-bounded waiver when the exception is genuinely required.

A practical CI sequence

npx @codapult/cli guard doctor
npx @codapult/cli guard check --changed --json
pnpm type-check
pnpm lint
pnpm test
npx @codapult/cli guard verify --json

Keep Guard's generated state in the project repository when it is part of the team's architecture record. Review policy changes like code changes: a new rule changes what future work can merge.

Complete the release evidence

Guard works alongside TypeScript, ESLint, tests, SAST, provider acceptance tests, and human PR review. A clean Guard result confirms that changed code satisfies the configured architecture policy; pair it with the other release checks to verify provider configuration, backups, and deployment readiness.