2826b28645
Replaces DNS-based discovery (2/34 agents) with Docker API enumeration to discover ALL running CHORUS containers. Implementation: - NEW: internal/p2p/swarm_discovery.go (261 lines) * Docker API client for Swarm task enumeration * Extracts container IPs from network attachments * Optional health verification before registration * Comprehensive error handling and logging - MODIFIED: internal/p2p/discovery.go (~50 lines) * Integrated Swarm discovery with fallback to DNS * New config: DISCOVERY_METHOD (swarm/dns/auto) * Tries Swarm first, falls back gracefully * Backward compatible with existing DNS discovery - NEW: IMPLEMENTATION-SUMMARY-Phase1-Swarm-Discovery.md * Complete deployment guide * Testing checklist * Performance metrics * Phase 2 roadmap Expected Results: - Discovery: 34/34 agents (100% vs previous ~6%) - Council activation: Both core roles claimed - Task execution: Unblocked Security: - Read-only Docker socket mount - No privileged mode required - Minimal API surface (TaskList + Ping only) Next: Build image, deploy, verify discovery, activate council Part of hybrid approach: - Phase 1: Docker API (this commit) ✅ - Phase 2: NATS migration (planned Week 3) Related: - /home/tony/chorus/docs/DIAGNOSIS-Agent-Discovery-And-P2P-Architecture.md - /home/tony/chorus/docs/ARCHITECTURE-ANALYSIS-LibP2P-HMMM-Migration.md 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
WHOOSH – Council & Team Orchestration (Beta)
WHOOSH assembles kickoff councils from Design Brief issues and is evolving toward autonomous team orchestration across the CHORUS stack. Council formation/deployment works today, but persistence, telemetry, and self-organising teams are still under construction.
Current Capabilities
- ✅ Gitea Design Brief detection + council composition (
internal/monitor,internal/composer). - ✅ Docker Swarm agent deployment with role-specific env vars (
internal/orchestrator). - ✅ JWT authentication, rate limiting, OpenTelemetry hooks.
- 🚧 API persistence: REST handlers still return placeholder data while Postgres wiring is finished (
internal/server/server.go). - 🚧 Analysis ingestion: composer relies on heuristic classification; LLM/analysis ingestion is logged but unimplemented (
internal/composer/service.go). - 🚧 Deployment telemetry: results aren’t persisted yet; monitoring includes TODOs for task details (
internal/monitor/monitor.go). - 🚧 Autonomous teams: joining/role balancing planned but not live.
The full plan and sequencing live in:
docs/progress/WHOOSH-roadmap.mddocs/DEVELOPMENT_PLAN.md
Quick Start
git clone https://gitea.chorus.services/tony/WHOOSH.git
cd WHOOSH
cp .env.example .env
# Update DB, JWT, Gitea tokens
make migrate
go run ./cmd/whoosh
By default the API runs on :8080 and expects Postgres + Docker Swarm in the environment. Until persistence lands, project/council endpoints return mock payloads to keep the UI working.
Roadmap Snapshot
- Data path hardening – replace mock handlers with real Postgres reads/writes.
- Telemetry – Persist deployment outcomes, emit KACHING events, build dashboards.
- Autonomous loop – Drive team formation/joining from composer outputs, tighten HMMM collaboration.
- UX & governance – Admin dashboards, compliance hooks, Decision Records.
Refer to the roadmap for sprint-by-sprint targets and exit criteria.
Working With Councils
- Monitor issues via the API (
GET /api/v1/councils). - Inspect generated artifacts (
GET /api/v1/councils/{id}/artifacts). - Use Swarm to watch agent containers spin up/down during council execution.
Contributing
Before landing features, align with roadmap tickets (WSH-API, WSH-ANALYSIS, WSH-OBS, WSH-AUTO, WSH-UX). Include Decision Records (UCXL addresses) for architectural/security changes so SLURP/BUBBLE can ingest them later.