tony/WHOOSH
1
0
Fork 0
Code Issues 6 Pull Requests Actions Packages Projects Releases Wiki Activity
Files
38d1d56cc6885d15037fe70b5a7e057894f8ffef
WHOOSH/docs/progress/WHOOSH-roadmap.md
Anthony Rawlins 7c1c80a8b5
Some checks failed
WHOOSH CI / speclint (push) Has been cancelled
Details
WHOOSH CI / contracts (push) Has been cancelled
Details
Add WHOOSH roadmap
2025-09-20 03:07:54 +00:00

3.4 KiB
Raw Blame History

WHOOSH Roadmap

Last updated: 2025-02-15

This roadmap breaks the WHOOSH council formation platform into phased milestones, sequencing the work needed to evolve from the current council-focused release to fully autonomous team orchestration with reliable telemetry and UI coverage.

Phase 0 – Alignment & Readiness (Week 0)

  • Confirm owners for API/persistence, analysis ingestion, deployment orchestrator, and UI work streams.
  • Audit existing deployments (Docker Swarm + Postgres) for parity with production configs.
  • Capture outstanding tech debt from DEVELOPMENT_PLAN.md into tracking tooling with the milestone tags below.

Exit criteria

  • Ownership assigned with sprint plans.
  • Backlog groomed with roadmap milestone labels (WSH-API, WSH-ANALYSIS, WSH-OBS, WSH-AUTO, WSH-UX).

Phase 1 – Hardening the Data Path (Weeks 1–4)

  • WSH-API (Weeks 1–2)
    • Replace mock project/council handlers with Postgres read/write paths.
    • Add migrations + integration tests for repository, issue, council, and artifact tables.
  • WSH-ANALYSIS (Weeks 2–4)
    • Pipe Gitea/n8n analysis results into composer inputs (tech stack, requirements, risk flags).
    • Persist analysis snapshots and expose via API.

Exit criteria

  • WHOOSH API/UI operates solely on persisted data; no mock payloads in server handlers.
  • New/Analyze flows populate composer with real issue metadata.

Phase 2 – Deployment Telemetry & Observability (Weeks 4–7)

  • WSH-OBS (Weeks 4–6)
    • Record deployment results in database and surface status in API/UI.
    • Instrument Swarm deployment with structured logs + Prometheus metrics (success/failure, duration).
  • WSH-TELEM (Weeks 5–7)
    • Emit telemetry events for KACHING (council/job counts, agent minutes, failure alerts).
    • Build Grafana/Metabase dashboards for council throughput and deployment health.

Exit criteria

  • Deployment outcomes visible in UI and exportable via API.
  • Telemetry feeds KACHING pipeline with validated sample data; dashboards in place.

Phase 3 – Autonomous Team Evolution (Weeks 7–10)

  • WSH-AUTO (Weeks 7–9)
    • Turn composer outputs into actionable team formation + self-joining flows.
    • Enforce role availability caps, load balancing, and join/leave workflows.
  • WSH-COLLAB (Weeks 8–10)
    • Integrate HMMM rooms & capability announcements for formed teams.
    • Add escalation + review loops via SLURP/BUBBLE decision hooks.

Exit criteria

  • Councils hand off to autonomous teams with recorded assignments.
  • Team state synced to SLURP/BUBBLE/HMMM; QA sign-off on end-to-end kickoff-to-deliverable scenario.

Phase 4 – UX & Governance (Weeks 10–12)

  • WSH-UX (Weeks 10–11)
    • Polish admin dashboard: council progress, telemetry widgets, failure triage.
    • Document operator runbooks in docs/admin-guide.
  • WSH-GOV (Weeks 11–12)
    • Generate Decision Records for major orchestration flows (UCXL addresses linked).
    • Finalize compliance hooks (SHHH redaction, audit exports).

Exit criteria

  • Admin/operator journeys validated; documentation complete.
  • Decision Records published; compliance/audit requirements satisfied.

Tracking & Reporting

  • Weekly sync across work streams with burndown, blocker, and risk review.
  • Metrics to monitor: council formation latency, deployment success %, telemetry delivery rate, autonomous team adoption.
  • All major architecture/security decisions recorded in SLURP/BUBBLE at the relevant UCXL addresses.