Commit Standards
Relevant source files
The following files were used as context for generating this wiki page:
Commit Standards in the Canon Guard project establish a rigorous framework for version control, ensuring that all changes to the repository are documented consistently and meet quality benchmarks before being merged. This system relies on automated linting, conventional commit specifications, and git hooks to maintain a clean and navigable project history.
The primary purpose of these standards is to facilitate automated versioning and changelog generation while ensuring that every contribution adheres to the project's formatting and structural requirements.
Sources: commitlint.config.js:1, package.json:54-65, CLAUDE.md:46-51
Conventional Commits
The project enforces the Conventional Commits specification. This is managed through commitlint, which validates commit messages against a standard set of rules. By extending the conventional configuration, the project ensures that commit messages are structured with a type (e.g., feat, fix, docs), an optional scope, and a descriptive subject.
Sources: commitlint.config.js:1, package.json:69-70
Commit Message Validation Flow
This diagram illustrates how a developer's commit attempt is intercepted and validated by the project's tooling.
The validation process ensures that no non-compliant messages enter the repository history.
Sources: package.json:69-70, commitlint.config.js:1
Automated Linting and Git Hooks
The project utilizes husky to manage Git hooks, specifically triggering validation tasks during the commit process. The lint-staged configuration ensures that only the files being committed are checked, which optimizes the development workflow.
Pre-commit Tasks
When a developer attempts to commit code, the following actions are automatically performed on the staged files:
| File Type / Pattern | Tool / Command | Purpose |
|---|---|---|
*.{js,css,md,ts,sol} | forge fmt | Ensures consistent formatting across major file types. |
(src|script|test)/**/*.sol | yarn lint:sol --fix | Runs Solhint to enforce Solidity style guides and fix auto-fixable issues. |
src/**/*.sol | lintspec | Specialized linting for source contracts. |
test/unit/**/*.tree | yarn lint:bulloak | Validates Bulloak tree files used for unit test specifications. |
package.json | sort-package-json | Maintains a consistent order for keys in the package configuration. |
Sources: package.json:54-65, CLAUDE.md:46-51
Code Quality Requirements
Beyond commit message structure, the "Commit Standards" are supported by a suite of linting scripts that are expected to pass before code is finalized.
- Solidity Linting: The project uses
solhintto analyze Solidity files insrc,script, andtestdirectories. - Formatting:
forge fmtis the primary tool for maintaining code style consistency. - Test Specifications: Unit tests are specified using
.treefiles, which are checked for consistency viabulloak.
Quality Check Commands
| Command | Description |
|---|---|
yarn lint:check | Runs forge fmt --check and solhint to verify project-wide compliance. |
yarn lint:fix | Automatically corrects formatting and Solhint issues where possible. |
yarn lint:bulloak | Specifically checks the structural integrity of test specification files. |
Sources: package.json:33-37, CLAUDE.md:46-51
Configuration Summary
The standards are defined through several key configuration files within the repository.
The relationship between these files defines the automated enforcement of the standards.
Sources: package.json:1, commitlint.config.js:1, foundry.toml:1-10
By adhering to these commit standards, the Canon Guard project maintains high internal code quality and a professional, machine-readable repository history that supports its security-focused multisig architecture.