46 lines
2.0 KiB
Markdown
46 lines
2.0 KiB
Markdown
|
# Notes: Dual Telemetry Control Panel
|
||
|
|
|
||
|
|
## Working Assumptions
|
||
|
|
- The chat page already has a persistent right-side `OrchestrationPanel`.
|
||
|
|
- Existing chat streaming already emits real `progress`, `chunk`, and `error`-style events.
|
||
|
|
- The user wants the panel to feel like an active system console, not a static status card.
|
||
|
|
|
||
|
|
## Design Intent
|
||
|
|
- Upper telemetry block: real machine metrics with micro line charts
|
||
|
|
- Lower telemetry block: session activity waveform tied to current chat execution
|
||
|
|
- Keep the visual language in the current sci-fi / HUD style
|
||
|
|
- Avoid heavy chart libraries or full dashboard aesthetics
|
||
|
|
|
||
|
|
## Constraints
|
||
|
|
- Do not invent fake system numbers
|
||
|
|
- Do not persist telemetry history into conversation history
|
||
|
|
- Keep the main chat surface dominant
|
||
|
|
- MVP should use the fewest new moving parts possible
|
||
|
|
|
||
|
|
## Current Code Findings
|
||
|
|
|
||
|
|
### `src/components/chat/OrchestrationPanel.vue`
|
||
|
|
- Already owns the visual shell for the right-side control panel
|
||
|
|
- Has logical places to insert additional stacked sections above the agent bus and event feed
|
||
|
|
- Current UI is text-forward and would benefit from live numeric/sparkline blocks
|
||
|
|
|
||
|
|
### `src/pages/chat/composables/useChatView.ts`
|
||
|
|
- Already maintains transient orchestration state per request
|
||
|
|
- Is the right place to derive a session activity waveform from `progress`, `tool`, and `chunk` events
|
||
|
|
- Can own polling lifecycle for system metrics if we want chat page-local state
|
||
|
|
|
||
|
|
### Backend status route
|
||
|
|
- No dedicated system metrics endpoint has been confirmed yet
|
||
|
|
- Minimal new backend contract can be a polling endpoint like `/api/system/status`
|
||
|
|
- Suggested payload:
|
||
|
|
- `cpu_percent`
|
||
|
|
- `memory_percent`
|
||
|
|
- `disk_percent`
|
||
|
|
- `timestamp`
|
||
|
|
|
||
|
|
## Planning Implications
|
||
|
|
- Add a tiny backend router/service for system telemetry rather than overloading conversation APIs
|
||
|
|
- Add a reusable lightweight sparkline component in frontend for consistent rendering
|
||
|
|
- Keep system telemetry and session telemetry separate in state and UI
|
||
|
|
- Limit retained chart points (for example 20-30) to keep rendering simple and responsive
|