Branching strategy
Promote v0 changes through isolated development and release lanes.
Version v0.1 of the documentation is no longer actively maintained. The site that you are currently viewing is an archived snapshot. For up-to-date documentation, see the latest version.
Contributing
Develop, test, and document changes locally.
Issues and pull requests are welcome. Keep changes narrow, preserve the security boundaries, and include evidence proportional to the risk.
Development setup
The aibox workspace installs the pinned Rust toolchain and cargo-audit.
The production implementation is entirely Rust. Python and uv are
development-only dependencies for repository policy, OpenTofu, and Ansible
tests; they are not part of the installed product.
uv sync --all-groups
scripts/bootstrap-security-tools
scripts/validate-all
scripts/test-all
Python, Rust, and Markdown lines are hard-wrapped at 80 columns. Use Conventional Commits and never bypass hooks.
Branches
main contains the latest published stable release. Normal implementation
work integrates through v0.x-dev; feature branches start from and merge back
to that branch.
See the branching strategy for the maintenance, development, prerelease, and stable-release promotion lanes.
Documentation
Build the site before opening a documentation change:
docs/scripts/build-docs.sh
Write task-oriented procedures as guides, stable facts as reference, and design rationale in concepts. Update the README only as the concise front door; the documentation site remains the detailed source.
Infrastructure changes
Infrastructure changes should include:
- strict contract or policy coverage;
- positive and negative tests;
- exact dependency pins;
- direct-tool equivalents;
- redacted evidence;
- a teardown plan before any live apply.
Live cost-bearing tests require separate explicit approval.