Thanks for contributing.
- One issue per concern.
- Non-trivial changes require a GitHub issue before implementation.
- Use release workflow controls; do not bypass them with manual shortcuts.
- Keep changes incremental and test-backed.
- Primary dev commands must run in the Windows environment.
- If you are operating from WSL2, invoke development commands through Windows context.
- Python 3.8+ is required.
developis the integration branch.mainis the release branch.- Normal delivery path: feature/fix ->
develop-> release PRdevelop->main. - Use hotfix flow only for urgent production fixes that must start from
main.
Run relevant test suites before PR:
bash tests/test_tm.sh
bash tests/test_edge_cases.shIf you touch release/governance logic, also ensure workflows pass on PR:
governance-baselinePublic Release Boundaryvalidate(repo-structure)Enforce main PR template (release or hotfix)(formainPRs)
Releases are controlled and must be reproducible.
- Prepare from
mainonly (unless explicit controlled override for dry-runs). - Run:
bash scripts/prepare-public-release.sh
- The release preparation now chains mandatory managers by default:
scripts/release-and-changelog-management.shscripts/release-public-docs-management.sh
- Publish tag explicitly:
bash scripts/publish-release-tag.sh vX.Y.Z
- Never use:
git push --tags
Use the release PR template and ensure these are checked:
release-and-changelog-management executedrelease-public-docs-management executed- artifact references are included in PR body
For each release, keep these public docs current and version-consistent:
VERSIONREADME.mdCHANGELOG.mdCONTRIBUTING.mdINSTALL.md/USAGE.md(if present)
- Use clear titles:
fix: ...,docs: ...,hardening: ...,release: .... - Keep PR scope focused.
- Link and close relevant issues explicitly in PR body.
- Do not merge if required checks are failing.