9aeaa433fc
- 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>
122 lines
7.2 KiB
Markdown
122 lines
7.2 KiB
Markdown
# WHOOSH UI Development Plan (Updated)
|
|
|
|
## 1. Overview
|
|
|
|
This document outlines the development plan for the WHOOSH UI, a web-based interface for interacting with the WHOOSH autonomous AI development team orchestration platform. This plan has been updated to reflect new requirements and a revised development strategy.
|
|
|
|
## 2. Development Strategy & Environment
|
|
|
|
To accelerate development and testing, we will adopt a decoupled approach:
|
|
|
|
- **Local Development Server:** A lightweight, local development server will be used to serve the existing UI files from `/home/tony/chorus/project-queues/active/WHOOSH/ui`. This allows for rapid iteration on the frontend without requiring a full container rebuild for every change.
|
|
- **Live API Backend:** The local UI will connect directly to the existing, live WHOOSH API endpoints at `https://whoosh.chorus.services`. This ensures the frontend is developed against the actual backend it will interact with.
|
|
- **Versioning:** A version number will be maintained for the UI. This version will be bumped incrementally with each significant build to ensure that deployed changes can be tracked and correlated with specific code versions.
|
|
|
|
## 3. User Requirements
|
|
|
|
The UI will address the following user requirements:
|
|
|
|
- **WHOOSH-REQ-001 (Revised):** Visualize the system's BACKBEAT cycle (downbeat, pulse, reverb) using a real-time, ECG-like display.
|
|
- **WHOOSH-REQ-002:** Model help promises and retry budgets in beats.
|
|
- **WHOOSH-INT-003:** Integrate Reverb summaries on team boards.
|
|
- **WHOOSH-MON-001:** Monitor council and team formation, including ideation phases.
|
|
- **WHOOSH-MON-002:** Monitor CHORUS agent configurations, including their assigned roles/personas and current tasks.
|
|
- **WHOOSH-MON-003:** Monitor CHORUS auto-scaling activities and SLURP leader elections.
|
|
- **WHOOSH-MGT-001:** Add and manage repositories for monitoring.
|
|
- **WHOOSH-VIZ-001:** Display a combined DAG/Venn diagram to visually represent agent-to-team membership and inter-agent collaboration within and across teams.
|
|
|
|
## 4. Branding and Design
|
|
|
|
The UI must adhere to the official Chorus branding guidelines. All visual elements, including logos, color schemes, typography, and iconography, should be consistent with the Chorus brand identity.
|
|
|
|
- **Branding Guidelines and Assets:** `/home/tony/chorus/project-queues/active/chorus.services/brand-assets`
|
|
- **Brand Website:** `/home/tony/chorus/project-queues/active/brand.chorus.services`
|
|
|
|
## 5. Development Phases
|
|
|
|
### Phase 1: Foundation & BACKBEAT Visualization
|
|
|
|
**Objective:** Establish the local development environment and implement the core BACKBEAT monitoring display.
|
|
|
|
**Tasks:**
|
|
|
|
1. **Local Development Environment Setup:**
|
|
* Configure a simple local web server to serve the existing static files in the `ui/` directory.
|
|
* Diagnose and fix the initial loading issue preventing the current UI from rendering.
|
|
* Establish the initial versioning system for the UI.
|
|
|
|
2. **API Integration:**
|
|
* Create a reusable API client to interact with the WHOOSH backend APIs at `https://whoosh.chorus.services`.
|
|
* Implement authentication handling for JWT tokens if required.
|
|
|
|
3. **BACKBEAT Visualization (WHOOSH-REQ-001):**
|
|
* Design and implement the main dashboard view.
|
|
* Fetch real-time data from the appropriate backend endpoint (`/admin/health/details` or `/metrics`).
|
|
* Implement an ECG-like visualization of the BACKBEAT cycle. This display must not use counters or beat numbers, focusing solely on the rhythmic flow of the downbeat, pulse, and reverb.
|
|
|
|
### Phase 2: Council, Team & Agent Monitoring
|
|
|
|
**Objective:** Implement features for monitoring the formation and status of councils, teams, and individual agents, including their interrelationships.
|
|
|
|
**Tasks:**
|
|
|
|
1. **System-Level Monitoring (WHOOSH-MON-003):**
|
|
* Create a dashboard component to display CHORUS auto-scaling events.
|
|
* Visualize CHORUS SLURP leader elections as they occur.
|
|
|
|
2. **Council & Team View (WHOOSH-MON-001):**
|
|
* Create views to display lists of councils and their associated teams.
|
|
* Monitor and display the status of council and team formation, including the initial ideation phase.
|
|
* Integrate and display Reverb summaries on team boards (`WHOOSH-INT-003`).
|
|
|
|
3. **Agent Detail View (WHOOSH-MON-002):**
|
|
* Within the team view, display detailed information for each agent.
|
|
* Show the agent's current configuration, assigned role/persona, and the specific task they are working on.
|
|
|
|
4. **Agent & Team Relationship Visualization (WHOOSH-VIZ-001):**
|
|
* Implement a dynamic visualization (DAG/Venn combo diagram) to illustrate which teams each agent is a part of and how agents collaborate. This will require fetching data on agent-team assignments and collaboration patterns from the backend.
|
|
|
|
### Phase 3: Repository & Task Management
|
|
|
|
**Objective:** Implement features for managing repositories and viewing tasks.
|
|
|
|
**Tasks:**
|
|
|
|
1. **Repository Management (WHOOSH-MGT-001):**
|
|
* Create a view to display a list of all monitored repositories from the `GET /api/repositories` endpoint.
|
|
* Implement a form to add a new repository using the `POST /api/repositories` endpoint.
|
|
* Add functionality to trigger a manual sync for a repository via `POST /api/repositories/{id}/sync`.
|
|
|
|
2. **Task List View (WHOOSH-REQ-002):**
|
|
* Create a view to display a list of tasks from the `GET /api/tasks` endpoint.
|
|
* In the task detail view, model and display help promises and retry budgets in beats.
|
|
|
|
### Phase 4: UI Polish & Integration
|
|
|
|
**Objective:** Improve the overall user experience and prepare for integration with the main WHOOSH container.
|
|
|
|
**Tasks:**
|
|
|
|
1. **UI/UX Improvements:**
|
|
* Apply a consistent and modern design system.
|
|
* Ensure the UI is responsive and works well on various screen sizes.
|
|
* Add loading indicators, error messages, and other feedback mechanisms.
|
|
* Implement client-side routing for a seamless single-page application experience.
|
|
|
|
2. **Container Integration:**
|
|
* Once the UI is functional and polished, update the WHOOSH service's Dockerfile to build and serve the UI files, replacing the local development server setup.
|
|
|
|
## 6. Technology Stack
|
|
|
|
- **Frontend:** Start with the existing plain HTML, CSS, and JavaScript in the `ui/` directory.
|
|
- **Local Dev Server:** A simple Node.js-based server (like `live-server` or a basic Express app).
|
|
- **Styling:** A modern CSS framework like Tailwind CSS or Bootstrap is recommended.
|
|
- **API Client:** The built-in `fetch` API or a lightweight library like `axios`.
|
|
- **Visualization:** Consider libraries like D3.js, vis.js, or Mermaid.js for complex graph and diagram rendering.
|
|
|
|
## 7. Milestones
|
|
|
|
- **Milestone 1 (End of Week 1):** Phase 1 completed. Local development environment is running, and the dashboard displays a live, ECG-style BACKBEAT visualization.
|
|
- **Milestone 2 (End of Week 2):** Phase 2 completed. Users can monitor council/team formation, agent status, system-level scaling events, and view the agent/team relationship visualization.
|
|
- **Milestone 3 (End of Week 3):** Phase 3 completed. Users can add and manage repositories.
|
|
- **Milestone 4 (End of Week 4):** Phase 4 completed. The UI is polished, and a plan for final container integration is ready. |