Files
WHOOSH/UI_DEVELOPMENT_PLAN.md
Claude Code 9aeaa433fc Fix Docker Swarm discovery network name mismatch
- 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>
2025-10-10 10:35:25 +11:00

7.2 KiB

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.