-
Notifications
You must be signed in to change notification settings - Fork 4
Infrastructure CICD Project Governance
This section provides a high-level overview of the systems and policies that ensure the stability, security, and evolution of the Claude Sleuth toolkit. It covers the automated pipelines used for quality assurance and releases, the security protocols for vulnerability disclosure, and the governance model for community contributions.
The project utilizes GitHub Actions to maintain high code quality and automate the delivery of new versions. These workflows ensure that every change is verified against supported Python environments and that releases are consistently documented.
The continuous integration pipeline performs "smoke tests" to verify the integrity of the toolkit across multiple environments. It specifically targets Python versions 3.10, 3.11, and 3.12. The tests confirm that:
- Core dependencies can be installed successfully.
- Primary CLI tools (
task_runner.py,template_builder.py, andsetup.py) are executable and respond to--helpor--listcommands. - Critical libraries (e.g.,
pandas,httpx,rich) are correctly importable in the runtime environment.
The release workflow is triggered by the creation of a version tag (e.g., v1.0.0). It automates the generation of GitHub Release notes by parsing the CHANGELOG.md file using awk and sed to extract only the relevant entries for the new version.
For a deep dive into the specific shell commands and matrix configurations, see CI/CD: Smoke Tests & Release Automation.
Claude Sleuth follows a structured governance model to maintain the rigor required for intelligence investigation tools. This includes strict branching strategies and a coordinated disclosure policy for security vulnerabilities.
The project maintains a 48-hour acknowledgement SLA for reported vulnerabilities. Security issues are handled via a private communication channel to prevent premature disclosure of exploits that could impact ongoing investigations.
Contributions are managed through a "Fork and Pull" model. The main branch is protected and serves as the stable production-ready code. Contributors are required to use specific naming conventions for branches (e.g., feature/, fix/, docs/) and provide atomic, imperative commit messages.
For details on the disclosure timeline, PR requirements, and issue templates, see Contributing, Security & Issue Tracking.
The following diagrams illustrate the relationship between the GitHub infrastructure and the local development/execution environment.
This diagram shows how GitHub Actions interact with the core Python scripts and metadata files.
graph TD
subgraph "GitHub_Infrastructure"
CI_Workflow[".github/workflows/ci.yml"]
Release_Workflow[".github/workflows/release.yml"]
Security_Policy[".github/SECURITY.md"]
end
subgraph "Code_Entities"
TR["scripts/task_runner.py"]
TB["scripts/template_builder.py"]
SP["scripts/setup.py"]
CL["CHANGELOG.md"]
end
CI_Workflow -- "executes --help" --> TR
CI_Workflow -- "executes --help" --> TB
CI_Workflow -- "executes --list" --> SP
Release_Workflow -- "parses via awk" --> CL
This diagram maps the lifecycle of a change from a local feature branch to an automated GitHub Release.
graph LR
subgraph "Contributor_Space"
FB["feature/branch"]
PR["Pull Request"]
end
subgraph "Automation_Space"
SmokeTests["Smoke Tests (Py 3.10-3.12)"]
Tag["git v* tag"]
RelGen["release.yml"]
end
subgraph "Distribution"
GHR["GitHub Release"]
end
FB -- "push & open" --> PR
PR -- "triggers" --> SmokeTests
SmokeTests -- "on merge" --> Tag
Tag -- "triggers" --> RelGen
RelGen -- "creates" --> GHR
| Area | Policy / Tool | File Reference |
|---|---|---|
| Python Support | 3.10, 3.11, 3.12 | |
| Branching | Feature/Fix/Docs prefixes | |
| Vulnerability Reporting | Email (elb.pr.contact@gmail.com) | |
| SLA | 48h Ack / 5d Assessment | |
| Release Notes | Automated from CHANGELOG.md |