tuandClaude Opus 4.7
bd5a462a1e
The per-cluster dot now reflects how the workload ended up after the cluster's events, not the worst thing that happened inside it: if the most recent state transition in the cluster was "-> healthy", the dot turns green even when the cluster contains earlier degraded/warning events. Falls back to the existing dominantSev logic for clusters without any state transition (e.g. rollout-only clusters). Matches the reality that a rollout which briefly degrades and then recovers is a normal, healthy outcome — not a "warning" forever. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
oumta-dashboard plugin
Fullscreen view for the Oumta cluster dashboard (Go backend in oumta-dashboard/).
Open
- Oumta button in the hyprcrd top bar (next to Tasks)
window._oumtaToggle()from the console / other plugins
Close with ESC or the × button.
Views
- Overview — cluster state, workload counts, attention list
- Workloads — filterable table (name, state, replicas, cpu/mem, image, reason)
- Timeline — event stream; clicking a workload filters down to its own events
Namespaces
Tab row at the top. Currently two mocks (oumta-dev, oumta-beta). Real list comes from the backend once /api/namespaces exists.
Configuration
Hardwired at the top of oumta-dashboard.js in the CONFIG block:
- baseUrl — where the Oumta Go backend is reachable (default
http://localhost:8085). - authToken — optional, sent as
Authorization: Bearer …when non-empty. - pollIntervalSec — polling fallback cadence when SSE is unavailable. Default 15 s.
No UI settings panel: the dashboard only runs against one specific deployment, so exposing these as editable fields would be noise.
State today
Everything is mocked. The live indicator in the top right shows polling once the overlay is open, but no real HTTP call fires yet. See TODO.md for the integration plan.
Disabling
Add "oumta-dashboard" to the disabled array in data/plugins.json.