29 lines
1.7 KiB
Markdown
29 lines
1.7 KiB
Markdown
|
# Task Plan: Dual Telemetry Control Panel
|
||
|
|
|
||
|
|
## Goal
|
||
|
|
Add a minimal viable dual telemetry module to the chat page right-side JARVIS CONTROL panel so it shows real system metric sparklines (CPU/MEM/DISK) and live session activity telemetry from chat progress events, while staying consistent with the current sci-fi UI.
|
||
|
|
|
||
|
|
## Phases
|
||
|
|
- [x] Phase 1: Plan and setup
|
||
|
|
- [x] Phase 2: Research existing chat panel and data flow
|
||
|
|
- [ ] Phase 3: Define implementation approach and data contracts
|
||
|
|
- [ ] Phase 4: Review and deliver
|
||
|
|
|
||
|
|
## Key Questions
|
||
|
|
1. Which metrics should be real machine telemetry versus session-derived telemetry?
|
||
|
|
2. What is the smallest backend contract needed to make the panel feel actually alive?
|
||
|
|
3. How should the new chart blocks fit into the current control panel without overwhelming the chat area?
|
||
|
|
|
||
|
|
## Decisions Made
|
||
|
|
- Use a mixed telemetry model: system metrics from backend polling, session activity from existing stream events.
|
||
|
|
- Prefer lightweight SVG or custom-rendered sparklines instead of adding a charting library.
|
||
|
|
- Keep the current right-side control panel and insert telemetry blocks into it rather than creating a second dashboard.
|
||
|
|
- Make system metrics real: CPU, memory, and disk values must come from backend runtime state.
|
||
|
|
- Make session activity real: derive the waveform from actual progress, tool, and chunk events from the current chat stream.
|
||
|
|
|
||
|
|
## Errors Encountered
|
||
|
|
- Existing plan file reflected the earlier orchestration-panel-only scope: replaced it with the new telemetry-focused plan so current goals stay in attention.
|
||
|
|
|
||
|
|
## Status
|
||
|
|
**Currently in Phase 3** - Finalizing the implementation plan, file touch points, and minimal data contracts for the dual telemetry panel.
|