dd4ef0f5e3
## Problem WHOOSH was failing to update team deployment status with database errors: - ERROR: column 'deployment_status' of relation 'teams' does not exist (SQLSTATE 42703) - This prevented proper tracking of agent deployment progress ## Solution - **Added migration 007**: Creates deployment_status and deployment_message columns - **deployment_status VARCHAR(50)**: Tracks deployment state (pending/success/failed) - **deployment_message TEXT**: Stores deployment error messages or status details - **Added index**: For efficient deployment status queries - **Backward compatibility**: Sets default values for existing teams ## Impact - ✅ Fixes team deployment status tracking errors - ✅ Enables proper agent deployment monitoring - ✅ Maintains data consistency with existing teams - ✅ Improves query performance with new index This resolves the database errors that were preventing WHOOSH from tracking autonomous team deployment status. 🤖 Generated with [Claude Code](https://claude.ai/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.