Add CHORUS/WHOOSH roadmap
This commit is contained in:
70
docs/progress/CHORUS-WHOOSH-roadmap.md
Normal file
70
docs/progress/CHORUS-WHOOSH-roadmap.md
Normal file
@@ -0,0 +1,70 @@
|
||||
# CHORUS / WHOOSH Roadmap
|
||||
|
||||
_Last updated: 2025-02-15_
|
||||
|
||||
This roadmap translates the development plan into phased milestones with suggested sequencing and exit criteria. Durations are approximate and assume parallel work streams where practical.
|
||||
|
||||
## Phase 0 – Kick-off & Scoping (Week 0)
|
||||
- Confirm owners and staffing for SLURP, SHHH, COOEE, WHOOSH, UCXL, and KACHING work streams.
|
||||
- Finalize engineering briefs for each deliverable; align with plan in `CHORUS-WHOOSH-development-plan.md`.
|
||||
- Stand up tracking board (Kanban/Sprint) with milestone tags introduced below.
|
||||
|
||||
**Exit Criteria**
|
||||
- Owners assigned and briefs approved.
|
||||
- Roadmap milestones added to tracking tooling.
|
||||
|
||||
## Phase 1 – Security Substrate Foundations (Weeks 1–4)
|
||||
- **1.1 SLURP Core (Weeks 1–3)**
|
||||
- Implement storage/resolver/temporal components and leader integration (ticket group `SEC-SLURP`).
|
||||
- Ship integration tests covering admin-only operations and failover.
|
||||
- **1.2 SHHH Sentinel (Weeks 2–4)**
|
||||
- Build `pkg/shhh`, integrate with COOEE/WHOOSH logging, add audit metrics (`SEC-SHHH`).
|
||||
- **1.3 COOEE Mesh Monitoring (Weeks 3–4)**
|
||||
- Validate enrolment payloads, instrument mesh health, document ops runbook (`SEC-COOEE`).
|
||||
|
||||
**Exit Criteria**
|
||||
- SLURP passes integration suite with real context resolution.
|
||||
- SHHH redaction events visible in metrics/logs; regression tests in place.
|
||||
- COOEE dashboards/reporting operational; runbook published.
|
||||
|
||||
## Phase 2 – WHOOSH Data Path & Telemetry (Weeks 4–8)
|
||||
- **2.1 Persistence & API Hardening (Weeks 4–6)**
|
||||
- Replace mock handlers with Postgres-backed endpoints (`WHOOSH-API`).
|
||||
- **2.2 Analysis Ingestion (Weeks 5–7)**
|
||||
- Pipeline real Gitea/n8n analysis into composer/monitor (`WHOOSH-ANALYSIS`).
|
||||
- **2.3 Deployment Telemetry (Weeks 6–8)**
|
||||
- Persist deployment results, emit telemetry, surface status in UI (`WHOOSH-OBS`).
|
||||
- **2.4 Composer Enhancements (Weeks 7–8)**
|
||||
- Add LLM skill analysis with fallback heuristics; evaluation harness (`WHOOSH-COMP`).
|
||||
|
||||
**Exit Criteria**
|
||||
- WHOOSH API/UI reflects live database state.
|
||||
- Analysis-derived data present in team formation/deployment flows.
|
||||
- Telemetry events available for KACHING integration.
|
||||
|
||||
## Phase 3 – Cross-Cutting Governance & Tooling (Weeks 8–12)
|
||||
- **3.1 UCXL Spec & Validator (Weeks 8–10)**
|
||||
- Publish Spec 1.0, ship validator CLI with CI coverage (`UCXL-SPEC`).
|
||||
- **3.2 KACHING Telemetry (Weeks 9–11)**
|
||||
- Instrument CHORUS runtime & WHOOSH orchestrator, deploy ingestion/aggregation jobs (`KACHING-TELEM`).
|
||||
- **3.3 Governance Tooling (Weeks 10–12)**
|
||||
- Deliver DR templates, signed assertions workflow, scope-aware RUSTLE views (`GOV-TOOLS`).
|
||||
|
||||
**Exit Criteria**
|
||||
- UCXL validator integrated into CI for CHORUS/WHOOSH/RUSTLE.
|
||||
- KACHING receives events and triggers quota/budget alerts.
|
||||
- Governance docs/tooling published; RUSTLE displays redacted context correctly.
|
||||
|
||||
## Phase 4 – Stabilization & Launch Readiness (Weeks 12–14)
|
||||
- Regression testing across CHORUS/WHOOSH/UCXL/KACHING.
|
||||
- Security & compliance review for SHHH and telemetry pipelines.
|
||||
- Rollout plan: staged deployment, rollback procedures, support playbooks.
|
||||
|
||||
**Exit Criteria**
|
||||
- All milestone tickets closed with QA sign-off.
|
||||
- Production readiness review approved; launch window scheduled.
|
||||
|
||||
## Tracking & Reporting
|
||||
- Weekly status sync covering milestone burndown, risks, and cross-team blockers.
|
||||
- Metrics dashboard to include: SLURP leader uptime, SHHH redaction counts, COOEE peer health, WHOOSH deployment success rate, UCXL validation pass rate, KACHING alert volume.
|
||||
- Maintain Decision Records for key architecture/security choices at relevant UCXL addresses.
|
||||
Reference in New Issue
Block a user