**Problem**: The standardized label set was missing the `chorus-entrypoint`
label, which is present in CHORUS repository and required for triggering
council formation for project kickoffs.
**Changes**:
- Added `chorus-entrypoint` label (#ff6b6b) to `EnsureRequiredLabels()`
in `internal/gitea/client.go`
- Now creates 9 standard labels (was 8):
1. bug
2. bzzz-task
3. chorus-entrypoint (NEW)
4. duplicate
5. enhancement
6. help wanted
7. invalid
8. question
9. wontfix
**Testing**:
- Rebuilt and deployed WHOOSH with updated label configuration
- Synced labels to all 5 monitored repositories (whoosh-ui,
SequentialThinkingForCHORUS, TEST, WHOOSH, CHORUS)
- Verified all repositories now have complete 9-label set
**Impact**: All CHORUS ecosystem repositories now have consistent labeling
matching the CHORUS repository standard, enabling proper council formation
triggers.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
Problem: Councils couldn't be assigned to tasks because they didn't exist in teams table
- Foreign key constraint tasks_assigned_team_id_fkey required valid team record
- Councils ARE teams (special subtype for project kickoffs)
Solution: Create team record when forming council
- Added team INSERT in storeCouncilComposition()
- Use same UUID for both team.id and council.id
- Team name: 'Council: {ProjectName}'
- ON CONFLICT DO NOTHING for idempotency
Result: Tasks can now be assigned to councils, unblocking task execution
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
- Changed NetworkName from 'chorus_default' to 'chorus_net'
- This matches the actual network 'CHORUS_chorus_net' (service prefix added automatically)
- Fixes discovered_count:0 issue - now successfully discovering all 25 agents
- Updated IMPLEMENTATION-SUMMARY with deployment status
Result: All 25 CHORUS agents now discovered successfully via Docker Swarm API
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
Query the actual task_id from councils table instead of incorrectly
using council_id as task_id.
Issue: Council activation was failing to trigger team composition
because it was looking for a task with ID=council_id which doesn't exist.
Fix: Query SELECT task_id FROM councils WHERE id = council_id
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
Two critical fixes for E2E council workflow:
1. Reduced core council roles from 8 to 2 (tpm + senior-software-architect)
- Faster council formation
- Easier debugging
- Sufficient for initial project planning
2. Added broadcast to monitor path
- Monitor now broadcasts council opportunities to CHORUS agents
- Previously only webhook path had broadcast, monitor path missed it
- Added broadcaster parameter to NewMonitor()
- Broadcast sent after council formation with 30s timeout
Verified working:
- Council formation successful
- Broadcast to CHORUS agents confirmed
- Role claims received (TPM claimed and loaded)
- Persona status "loaded" acknowledged
Image: anthonyrawlins/whoosh:broadcast-fix
Council: 2dad2070-292a-4dbd-9195-89795f84da19
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
- Add scaling system components to server initialization
- Register scaling API and assignment broker routes
- Start bootstrap pool manager in server lifecycle
- Add graceful shutdown for scaling controller
- Update API routing to use chi.Router instead of gorilla/mux
- Fix Docker API compatibility issues
- Configure health gates with placeholder URLs for KACHING and BACKBEAT
🤖 Generated with [Claude Code](https://claude.ai/code)
Co-Authored-By: Claude <noreply@anthropic.com>
- Health gates system for pre-scaling validation (KACHING, BACKBEAT, bootstrap peers)
- Assignment broker API for per-replica configuration management
- Bootstrap pool management with weighted peer selection and health monitoring
- Wave-based scaling algorithm with exponential backoff and failure recovery
- Enhanced SwarmManager with Docker service scaling capabilities
- Comprehensive scaling metrics collection and reporting system
- RESTful HTTP API for external scaling operations and monitoring
- Integration with CHORUS P2P networking and assignment systems
🤖 Generated with [Claude Code](https://claude.ai/code)
Co-Authored-By: Claude <noreply@anthropic.com>
Resolves WHOOSH-LLM-002: Replace stubbed LLM functions with full Ollama API integration
## New Features
- Full Ollama API integration with automatic endpoint discovery
- LLM-powered task classification using configurable models
- LLM-powered skill requirement analysis
- Graceful fallback to heuristics on LLM failures
- Feature flag support for LLM vs heuristic execution
- Performance optimization with smaller, faster models (llama3.2:latest)
## Implementation Details
- Created OllamaClient with connection pooling and timeout handling
- Structured prompt engineering for consistent JSON responses
- Robust error handling with automatic failover to heuristics
- Comprehensive integration tests validating functionality
- Support for multiple Ollama endpoints with health checking
## Performance & Reliability
- Timeout configuration prevents hanging requests
- Fallback mechanism ensures system reliability
- Uses 3.2B parameter model for balance of speed vs accuracy
- Graceful degradation when LLM services unavailable
## Files Added
- internal/composer/ollama.go: Core Ollama API integration
- internal/composer/llm_test.go: Comprehensive integration tests
## Files Modified
- internal/composer/service.go: Implemented LLM functions
- internal/composer/models.go: Updated config for performance
🤖 Generated with [Claude Code](https://claude.ai/code)
Co-Authored-By: Claude <noreply@anthropic.com>
Fixed undefined types.ContainerLogsOptions error by using an inline struct
that matches the Docker API interface. This resolves compilation issues
with the GetServiceLogs method while maintaining compatibility with the
existing Docker v24.0.7 dependency.
🤖 Generated with [Claude Code](https://claude.ai/code)
Co-Authored-By: Claude <noreply@anthropic.com>
- Replace incremental sync with full scan for new repositories
- Add initial_scan status to bypass Since parameter filtering
- Implement council formation detection for Design Brief issues
- Add version display to WHOOSH UI header for debugging
- Fix Docker token authentication with trailing newline removal
- Add comprehensive council orchestration with Docker Swarm integration
- Include BACKBEAT prototype integration for distributed timing
- Support council-specific agent roles and deployment strategies
- Transition repositories to active status after content discovery
Key architectural improvements:
- Full scan approach for new project detection vs incremental sync
- Council formation triggered by chorus-entrypoint labeled Design Briefs
- Proper token handling and authentication for Gitea API calls
- Support for both initial discovery and ongoing task monitoring
This enables autonomous project kickoff workflows where Design Brief issues
automatically trigger formation of specialized agent councils for new projects.
🤖 Generated with [Claude Code](https://claude.ai/code)
Co-Authored-By: Claude <noreply@anthropic.com>
This commit resolves multiple blocking issues that were preventing WHOOSH from
properly detecting and converting bzzz-task labeled issues from Gitea:
## Issues Fixed:
1. **JSON Parsing Error**: Gitea API returns repository owner as string in issue
responses, but code expected User object. Added IssueRepository struct to
handle this API response format difference.
2. **Database Error Handling**: Code was using database/sql.ErrNoRows but
system uses pgx driver. Updated imports and error constants to use
pgx.ErrNoRows consistently.
3. **NULL Value Scanning**: Database fields (repository, project_id,
estimated_hours, complexity_score) can be NULL but Go structs used
non-pointer types. Added proper NULL handling with pointer scanning
and safe conversion.
## Results:
- ✅ WHOOSH now successfully detects bzzz-task labeled issues
- ✅ Task creation pipeline working end-to-end
- ✅ Tasks API functioning properly
- ✅ First bzzz-task converted: "Logic around registered agents faulty"
The core issue monitoring workflow is now fully operational and ready for
CHORUS integration.
🤖 Generated with [Claude Code](https://claude.ai/code)
Co-Authored-By: Claude <noreply@anthropic.com>
- Add database migrations for repositories, webhooks, and sync logs tables
- Implement full CRUD API for repository management
- Add web UI with repository list, add form, and management interface
- Support JSONB handling for topics and metadata
- Handle nullable database columns properly
- Integrate with existing WHOOSH dashboard and navigation
- Enable Gitea repository monitoring for issue tracking and CHORUS integration
🤖 Generated with [Claude Code](https://claude.ai/code)
Co-Authored-By: Claude <noreply@anthropic.com>
Features implemented:
- Real-time BACKBEAT pulse monitoring with current beat display
- ECG-like trace visualization with canvas-based rendering
- Downbeat detection and highlighting (every 4th beat)
- Phase monitoring (normal, degraded, recovery)
- Average beat interval tracking (2000ms intervals)
- Auto-refreshing data every second for real-time updates
API Integration:
- Added /api/v1/backbeat/status endpoint
- Returns simulated BACKBEAT data based on CHORUS log patterns
- JSON response includes beat numbers, phases, timing data
UI Components:
- BACKBEAT Clock card in dashboard overview
- Live pulse trace with 10-second rolling window
- Color-coded metrics display
- Grid background for ECG-style visualization
- Downbeat markers in red for emphasis
This provides visual feedback on the CHORUS system's distributed
coordination timing and autonomous AI team synchronization status.
🤖 Generated with [Claude Code](https://claude.ai/code)
Co-Authored-By: Claude <noreply@anthropic.com>
Replace mock endpoints with real database-backed task management:
- Add tasks table with full relationships and indexes
- Create generic task management service supporting multiple sources
- Implement GITEA integration service for issue synchronization
- Add task creation, retrieval, assignment, and status updates
Database schema changes:
- New tasks table with external_id mapping for GITEA/GitHub/Jira
- Foreign key relationships to teams and agents
- Task workflow tracking (claimed_at, started_at, completed_at)
- JSONB fields for labels, tech_stack, requirements
Task management features:
- Generic TaskFilter with pagination and multi-field filtering
- Automatic tech stack inference from labels and descriptions
- Complexity scoring based on multiple factors
- Real task assignment to teams and agents
- GITEA webhook integration for automated task sync
API endpoints now use real database operations:
- GET /api/v1/tasks (real filtering and pagination)
- GET /api/v1/tasks/{id} (database lookup)
- POST /api/v1/tasks/ingest (creates actual task records)
- POST /api/v1/tasks/{id}/claim (real assignment operations)
GITEA integration includes:
- Issue-to-task synchronization with configurable task labels
- Priority mapping from issue labels
- Estimated hours extraction from issue descriptions
- Webhook processing for real-time updates
This removes the major mocked components and provides
a foundation for genuine E2E testing with real data.
🤖 Generated with [Claude Code](https://claude.ai/code)
Co-Authored-By: Claude <noreply@anthropic.com>
Implement comprehensive task ingestion and management:
- POST /api/v1/tasks/ingest (manual and webhook task submission)
- GET /api/v1/tasks/{id} (task details retrieval)
- PUT /api/v1/teams/{id}/status (team status updates)
- PUT /api/v1/agents/{id}/status (agent status and metrics)
Add SLURP integration proxy endpoints:
- POST /api/v1/slurp/submit (artifact submission with UCXL addressing)
- GET /api/v1/slurp/retrieve (artifact retrieval by UCXL address)
- Database persistence for submission tracking
Implement project task management:
- GET /api/v1/projects/{id}/tasks (project task listing)
- GET /api/v1/tasks/available (available task discovery)
- POST /api/v1/tasks/{id}/claim (task claiming by teams)
Key features added:
- Async processing for complex tasks
- Tech stack inference from labels
- UCXL address generation for SLURP integration
- Team and agent validation
- Comprehensive request validation and error handling
- Structured logging for all operations
WHOOSH MVP now has fully functional API endpoints beyond
the core Team Composer service, providing complete task
lifecycle management and CHORUS ecosystem integration.
🤖 Generated with [Claude Code](https://claude.ai/code)
Co-Authored-By: Claude <noreply@anthropic.com>
Add sophisticated team formation engine with:
- Task analysis and classification algorithms
- Skill requirement detection and mapping
- Agent capability matching with confidence scoring
- Database persistence with PostgreSQL/pgx integration
- Production-ready REST API endpoints
API endpoints added:
- POST /api/v1/teams (create teams with analysis)
- GET /api/v1/teams (list teams with pagination)
- GET /api/v1/teams/{id} (get team details)
- POST /api/v1/teams/analyze (analyze without creating)
- POST /api/v1/agents/register (register new agents)
Core Team Composer capabilities:
- Heuristic task classification (9 task types)
- Multi-dimensional complexity assessment
- Technology domain identification
- Role-based team composition strategies
- Agent matching with skill/availability scoring
- Full database CRUD with transaction support
This moves WHOOSH from basic N8N workflow stubs to a fully
functional team composition system with real business logic.
🤖 Generated with [Claude Code](https://claude.ai/code)
Co-Authored-By: Claude <noreply@anthropic.com>
