3373f7b462
**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>
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.