This guide covers the day-to-day development workflow: branching, validation, committing, and submitting pull requests.
Create a branch with a descriptive name using these prefixes:
| Prefix | Purpose | Example |
|---|---|---|
feat/ |
New features | feat/add-sarif-output |
fix/ |
Bug fixes | fix/pattern-handler-escaping |
docs/ |
Documentation updates | docs/getting-started-guide |
refactor/ |
Code refactoring | refactor/simplify-sieve-pipeline |
test/ |
Test additions/fixes | test/cel-expression-coverage |
git checkout -b feat/my-featureRun all of these before every commit. They match the checks that CI will run on your pull request.
uv run ruff check .To auto-fix issues:
uv run ruff check --fix .To format code:
uv run ruff format .uv run pytest tests/ --ignore=tests/integration/ -qTo run only framework tests:
uv run pytest tests/darnit/ -vTo run only implementation tests:
uv run pytest tests/darnit_baseline/ -vuv run python scripts/validate_sync.py --verboseThis checks that the framework-design spec matches the implementation. If you've changed framework behavior, update the spec first.
uv run python scripts/generate_docs.pyCheck if docs changed:
git diff docs/generated/If they did, include the changes in your commit.
git fetch upstream
git rebase upstream/mainAlways rebase before pushing to keep history clean.
Write clear, concise commit messages:
type: short description
Longer description if needed explaining the what and why.
Types: feat, fix, docs, test, refactor, ci, chore
Examples:
feat: Add SARIF output formatter for audit results
fix: Correct CEL expression escaping in TOML literal strings
docs: Add getting started guide for contributors
-
Push your branch to your fork:
git push origin feat/my-feature
-
Open a Pull Request against the
mainbranch on the upstream repository. -
Fill out the PR template with:
- What changed and why
- How to test the changes
- Any breaking changes
-
Wait for CI checks to pass and address review feedback.
If you're modifying framework behavior (sieve pipeline, plugin protocol, configuration), follow this order:
- Update the spec first: Edit
openspec/specs/framework-design/spec.md - Validate sync:
uv run python scripts/validate_sync.py --verbose - Implement the change: Modify the code to match the spec
- Regenerate docs:
uv run python scripts/generate_docs.py - Commit spec, code, and docs together
- Follow existing code patterns and conventions
- Write clear, self-documenting code
- Add comments only where necessary to explain complex logic
- All public APIs should have type annotations
- Testing Guide — How to run and write tests
- Troubleshooting Guide — Common issues and solutions
- Back to Getting Started