[anomaly-detection + capacity-forecast UI: state and surfacing (OpenSpec add-causal-anomaly-detection, Phases 4.4 + 5.1-5.4)][recommendation] UI was specced (4.4, 5.1-5.4) and is built + merged to staging — reuse, don't rebuild #3730

New issue

Closed

opened 2026-06-13 05:14:05 +00:00 by mfreeman451 · 1 comment

mfreeman451 commented

2026-06-13 05:14:05 +00:00

Owner

Problem

This is a baseline-truth (positive) finding, not a gap. During the anomaly-detection deep dive it needed to be established whether the operator-facing UI for add-causal-anomaly-detection Phases 4.4 and 5.1–5.4 was ever built. It was: the settings editor (4.4) and the full Phase 5 UI surface (dashboard capacity-forecast visual, event-tile finding summary, placeholder subsume, RBAC) were authored and merged to origin/staging. The UI is genuinely code-complete.

Recording this so the other findings (the data spine being dead → empty UI, and the surfacing gaps) are correctly scoped as non-UI work that should reuse this substrate rather than re-implement it.

Severity

recommendation

Root cause

Phase 4.4 (settings editor) and Phase 5 (dashboard visual, event tile, placeholder subsume, RBAC) were authored and merged via the Phase 4.4 / 5.1 / 5.2 commits. The spec tasks are checked off and the code exists on origin/staging.

Evidence

Spec tasks (marked [x]):

openspec/changes/add-causal-anomaly-detection/tasks.md:46 — "4.4 Settings UI editor for the config (mirror the observability-rule-management / settings patterns); RBAC-gated."
openspec/changes/add-causal-anomaly-detection/tasks.md:49-52 — "5.1 Capacity-forecast visualization … 5.2 Anomaly findings surfaced in event_live; anomaly/at-risk summary tile via the Stats + rollup_stats pattern … 5.3 Subsume the bespoke placeholders … 5.4 RBAC gates consistent with existing observability/dashboard views."

Built (verified on origin/staging):

Settings editor: elixir/web-ng/lib/serviceradar_web_ng_web/live/settings/anomaly_detection_live.ex:1-461 — full two-form editor ("Operator-managed anomaly detection and capacity forecast settings").
Route: elixir/web-ng/lib/serviceradar_web_ng_web/router.ex:780 — live("/settings/anomaly-detection", Settings.AnomalyDetectionLive, :index).
Nav tab: elixir/web-ng/lib/serviceradar_web_ng_web/live/settings/settings_components.ex:326-329.
Capacity-forecast visual: elixir/web-ng/assets/component/src/DashboardPanelChart.jsx:200-211 (isCapacityForecastPanel) + :517-618 (CapacityForecastChart with current/projected/threshold ReferenceLine, upper/lower bounds, ETA).
Event finding tile: elixir/web-ng/lib/serviceradar_web_ng_web/live/event_live/index.ex:213-251 (event_finding_summary: Anomaly findings / At-risk capacity / Health findings) rendered at index.ex:111.

Git (all on origin/staging):

f2a9149d6 Add Phase 4.4 anomaly settings UI
957308b0f Add Phase 5.1 capacity forecast dashboard visual
dc2e5ade6 Add Phase 5.2 anomaly findings UI

PRs #3683 / #3684 carried the Phase 5 work.

Recommendation

Accept tasks 4.4 and 5.1–5.4 as code-complete and merged. Do not re-implement the UI. The remaining anomaly-detection findings are about:

the data spine being dead, so the UI renders empty (e.g. verdicts never reaching ocsf_events / StatefulAlertEngine, ACL denials, NACK poison loops — see the [anomaly][blocker] / [concern] issues), and
surfacing gaps (no device-details integration, no dedicated anomaly view).

Treat the existing UI components above as the reuse substrate for those follow-ups: fix the spine so the tiles/charts populate, and extend (not rebuild) event_finding_summary and CapacityForecastChart for any new surfaces.

🤖 Generated with Claude Code

## Problem This is a **baseline-truth (positive) finding**, not a gap. During the anomaly-detection deep dive it needed to be established whether the operator-facing UI for `add-causal-anomaly-detection` Phases 4.4 and 5.1–5.4 was ever built. It was: the settings editor (4.4) and the full Phase 5 UI surface (dashboard capacity-forecast visual, event-tile finding summary, placeholder subsume, RBAC) were authored and merged to `origin/staging`. The UI is genuinely code-complete. Recording this so the other findings (the data spine being dead → empty UI, and the surfacing gaps) are correctly scoped as *non-UI* work that should **reuse** this substrate rather than re-implement it. ## Severity recommendation ## Root cause Phase 4.4 (settings editor) and Phase 5 (dashboard visual, event tile, placeholder subsume, RBAC) were authored and merged via the Phase 4.4 / 5.1 / 5.2 commits. The spec tasks are checked off and the code exists on `origin/staging`. ## Evidence Spec tasks (marked `[x]`): - `openspec/changes/add-causal-anomaly-detection/tasks.md:46` — "4.4 Settings UI editor for the config (mirror the observability-rule-management / settings patterns); RBAC-gated." - `openspec/changes/add-causal-anomaly-detection/tasks.md:49-52` — "5.1 Capacity-forecast visualization … 5.2 Anomaly findings surfaced in `event_live`; anomaly/at-risk summary tile via the `Stats` + `rollup_stats` pattern … 5.3 Subsume the bespoke placeholders … 5.4 RBAC gates consistent with existing observability/dashboard views." Built (verified on `origin/staging`): - Settings editor: `elixir/web-ng/lib/serviceradar_web_ng_web/live/settings/anomaly_detection_live.ex:1-461` — full two-form editor ("Operator-managed anomaly detection and capacity forecast settings"). - Route: `elixir/web-ng/lib/serviceradar_web_ng_web/router.ex:780` — `live("/settings/anomaly-detection", Settings.AnomalyDetectionLive, :index)`. - Nav tab: `elixir/web-ng/lib/serviceradar_web_ng_web/live/settings/settings_components.ex:326-329`. - Capacity-forecast visual: `elixir/web-ng/assets/component/src/DashboardPanelChart.jsx:200-211` (`isCapacityForecastPanel`) + `:517-618` (`CapacityForecastChart` with current/projected/threshold `ReferenceLine`, upper/lower bounds, ETA). - Event finding tile: `elixir/web-ng/lib/serviceradar_web_ng_web/live/event_live/index.ex:213-251` (`event_finding_summary`: Anomaly findings / At-risk capacity / Health findings) rendered at `index.ex:111`. Git (all on `origin/staging`): - `f2a9149d6` Add Phase 4.4 anomaly settings UI - `957308b0f` Add Phase 5.1 capacity forecast dashboard visual - `dc2e5ade6` Add Phase 5.2 anomaly findings UI PRs #3683 / #3684 carried the Phase 5 work. ## Recommendation Accept tasks 4.4 and 5.1–5.4 as **code-complete and merged**. Do not re-implement the UI. The remaining anomaly-detection findings are about: 1. the data spine being dead, so the UI renders empty (e.g. verdicts never reaching `ocsf_events` / `StatefulAlertEngine`, ACL denials, NACK poison loops — see the `[anomaly][blocker]` / `[concern]` issues), and 2. surfacing gaps (no device-details integration, no dedicated anomaly view). Treat the existing UI components above as the **reuse substrate** for those follow-ups: fix the spine so the tiles/charts populate, and extend (not rebuild) `event_finding_summary` and `CapacityForecastChart` for any new surfaces. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

mfreeman451 referenced this issue

2026-06-13 05:16:04 +00:00

[anomaly-detection + capacity-forecast UI: state and surfacing (OpenSpec add-causal-anomaly-detection, Phases 4.4 + 5.1-5.4)][recommendation] No dedicated anomaly / observability-health view — findings live only in the generic event stream #3734

mfreeman451 commented

2026-06-13 09:11:15 +00:00

Author

Owner

Closed as already addressed before this investigation: the OpenSpec UI phases were built and merged, and the actionable follow-ups are tracked separately in #3731, #3733, #3734, #3736, and #3752.