f010a0c8a2
This commit implements Phase 4 of the CHORUS task execution engine development plan, replacing the MockTaskProvider with real repository provider implementations for Gitea, GitHub, and GitLab APIs. ## Major Components Added: ### Repository Providers (pkg/providers/) - **GiteaProvider**: Complete Gitea API integration for self-hosted Git services - **GitHubProvider**: GitHub API integration with comprehensive issue management - **GitLabProvider**: GitLab API integration supporting both cloud and self-hosted - **ProviderFactory**: Centralized factory for creating and managing providers - **Comprehensive Testing**: Full test suite with mocks and validation ### Key Features Implemented: #### Gitea Provider Integration - Issue retrieval with label filtering and status management - Task claiming with automatic assignment and progress labeling - Completion handling with detailed comments and issue closure - Priority/complexity calculation from labels and content analysis - Role and expertise determination from issue metadata #### GitHub Provider Integration - GitHub API v3 integration with proper authentication - Pull request filtering (issues only, no PRs as tasks) - Rich completion comments with execution metadata - Label management for task lifecycle tracking - Comprehensive error handling and retry logic #### GitLab Provider Integration - Supports both GitLab.com and self-hosted instances - Project ID or owner/repository identification - GitLab-specific features (notes, time tracking, milestones) - Issue state management and assignment handling - Flexible configuration for different GitLab setups #### Provider Factory System - **Dynamic Provider Creation**: Factory pattern for provider instantiation - **Configuration Validation**: Provider-specific config validation - **Provider Discovery**: Runtime provider enumeration and info - **Extensible Architecture**: Easy addition of new providers #### Intelligent Task Analysis - **Priority Calculation**: Multi-factor priority analysis from labels, titles, content - **Complexity Estimation**: Content analysis for task complexity scoring - **Role Determination**: Automatic role assignment based on label analysis - **Expertise Mapping**: Technology and skill requirement extraction ### Technical Implementation Details: #### API Integration: - HTTP client configuration with timeouts and proper headers - JSON marshaling/unmarshaling for API request/response handling - Error handling with detailed API response analysis - Rate limiting considerations and retry mechanisms #### Security & Authentication: - Token-based authentication for all providers - Secure credential handling without logging sensitive data - Proper API endpoint URL construction and validation - Request sanitization and input validation #### Task Lifecycle Management: - Issue claiming with conflict detection - Progress tracking through label management - Completion reporting with execution metadata - Status updates with rich markdown formatting - Automatic issue closure on successful completion ### Configuration System: - Flexible configuration supporting multiple provider types - Environment variable expansion and validation - Provider-specific required and optional fields - Configuration validation with detailed error messages ### Quality Assurance: - Comprehensive unit tests with HTTP mocking - Provider factory testing with configuration validation - Priority/complexity calculation validation - Role and expertise determination testing - Benchmark tests for performance validation This implementation enables CHORUS agents to work with real repository systems instead of mock providers, allowing true autonomous task execution across different Git platforms. The system now supports the major Git hosting platforms used in enterprise and open-source development, with a clean abstraction that allows easy addition of new providers. 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <noreply@anthropic.com>
CHORUS – Container-First Context Platform (Alpha)
CHORUS is the runtime that ties the CHORUS ecosystem together: libp2p mesh, DHT-backed storage, council/task coordination, and (eventually) SLURP contextual intelligence. The repository you are looking at is the in-progress container-first refactor. Several core systems boot today, but higher-level services (SLURP, SHHH, full HMMM routing) are still landing.
Current Status
| Area | Status | Notes |
|---|---|---|
| libp2p node + PubSub | ✅ Running | internal/runtime/shared.go spins up the mesh, hypercore logging, availability broadcasts. |
| DHT + DecisionPublisher | ✅ Running | Encrypted storage wired through pkg/dht; decisions written via ucxl.DecisionPublisher. |
| Leader Election System | ✅ FULLY FUNCTIONAL | 🎉 MILESTONE: Complete admin election with consensus, discovery protocol, heartbeats, and SLURP activation! |
| SLURP (context intelligence) | 🚧 Stubbed | pkg/slurp/slurp.go contains TODOs for resolver, temporal graphs, intelligence. Leader integration scaffolding exists but uses placeholder IDs/request forwarding. |
| SHHH (secrets sentinel) | 🚧 Sentinel live | pkg/shhh redacts hypercore + PubSub payloads with audit + metrics hooks (policy replay TBD). |
| HMMM routing | 🚧 Partial | PubSub topics join, but capability/role announcements and HMMM router wiring are placeholders (internal/runtime/agent_support.go). |
See docs/progress/CHORUS-WHOOSH-development-plan.md for the detailed build plan and docs/progress/CHORUS-WHOOSH-roadmap.md for sequencing.
Quick Start (Alpha)
The container-first workflows are still evolving; expect frequent changes.
git clone https://gitea.chorus.services/tony/CHORUS.git
cd CHORUS
cp docker/chorus.env.example docker/chorus.env
# adjust env vars (KACHING license, bootstrap peers, etc.)
docker compose -f docker/docker-compose.yml up --build
You’ll get a single agent container with:
- libp2p networking (mDNS + configured bootstrap peers)
- election heartbeat
- DHT storage (AGE-encrypted)
- HTTP API + health endpoints
Missing today: SLURP context resolution, advanced SHHH policy replay, HMMM per-issue routing. Expect log warnings/TODOs for those paths.
🎉 Leader Election System (NEW!)
CHORUS now features a complete, production-ready leader election system:
Core Features
- Consensus-based election with weighted scoring (uptime, capabilities, resources)
- Admin discovery protocol for network-wide leader identification
- Heartbeat system with automatic failover (15-second intervals)
- Concurrent election prevention with randomized delays
- SLURP activation on elected admin nodes
How It Works
- Bootstrap: Nodes start in idle state, no admin known
- Discovery: Nodes send discovery requests to find existing admin
- Election trigger: If no admin found after grace period, trigger election
- Candidacy: Eligible nodes announce themselves with capability scores
- Consensus: Network selects winner based on highest score
- Leadership: Winner starts heartbeats, activates SLURP functionality
- Monitoring: Nodes continuously verify admin health via heartbeats
Debugging
Use these log patterns to monitor election health:
# Monitor WHOAMI messages and leader identification
docker service logs CHORUS_chorus | grep "🤖 WHOAMI\|👑\|📡.*Discovered"
# Track election cycles
docker service logs CHORUS_chorus | grep "🗳️\|📢.*candidacy\|🏆.*winner"
# Watch discovery protocol
docker service logs CHORUS_chorus | grep "📩\|📤\|📥"
Roadmap Highlights
- Security substrate – land SHHH sentinel, finish SLURP leader-only operations, validate COOEE enrolment (see roadmap Phase 1).
- Autonomous teams – coordinate with WHOOSH for deployment telemetry + SLURP context export.
- UCXL + KACHING – hook runtime telemetry into KACHING and enforce UCXL validator.
Track progress via the shared roadmap and weekly burndown dashboards.
Related Projects
- WHOOSH – council/team orchestration
- KACHING – telemetry/licensing
- SLURP – contextual intelligence prototypes
- HMMM – meta-discussion layer
Contributing
This repo is still alpha. Please coordinate via the roadmap tickets before landing changes. Major security/runtime decisions should include a Decision Record with a UCXL address so SLURP/BUBBLE can ingest it later.