In this section: How C-DAD Works

cdad validate

A contract is only useful while it's true. The moment the code changes and nobody updates the contract next to it, you're back to documentation that lies, which is arguably worse than no documentation at all. cdad validate <path> is the command that catches that drift before it ships. It checks the contract files against the schema, enforces the versioning rules, and confirms the generated artifacts still match what the contract actually declares.

Run it against a single path while you're working on one capability, or add --all to validate every contract in the repo at once, which is what most teams run in CI. --strictturns warnings into errors, so a check that would otherwise pass with a note now fails the build. If a problem has a safe automatic fix, --fix will apply it rather than just flagging it, and --format json gives you machine-readable output if another tool needs to consume the results.

The flag worth calling out specifically is --install-hook. It installs a POSIX shell pre-commit hook that runs validation automatically before a commit lands, which is the difference between "we're supposed to validate contracts" and contracts that actually stay validated. Most teams run this once, early, and then forget it's there because it just quietly does its job on every commit.

The recommended point to run this by hand is right before a PR:cdad validate --all --strict, so nothing with a stale or malformed contract merges in the first place.

cdad validate cdad/payments/retries/schedule-retry
cdad validate --all --strict