Summary

HPAs can fail quietly: the target workload may still have healthy-looking pods while autoscaling is capped, unable to read metrics, pinned by configuration, or paused at zero replicas. This PR makes HPA diagnosis a first-class Radar insight so operators can understand autoscaling state directly from Radar instead of reconstructing it from raw HPA conditions.

The goal is not to turn every HPA condition into an alert. The branch separates high-signal list/dashboard states from richer drawer context: broken/capped autoscaling is surfaced prominently, while states like min-bound, stale status, partial metrics, and stabilization remain available in detail views without adding table noise.

What Changed

Shared HPA Diagnosis Engine

• Added pkg/hpadiag, a shared Go analyzer for autoscaling/v2 HPAs.
• The analyzer produces a structured Diagnosis with:
  • state: normalized HPA state such as limited_max, metrics_unavailable, unable_to_scale, disabled, pinned, stale, stabilized, scaling_up, and ok.
  • summary: operator-facing text intended for Radar UI / AI context.
  • target: scale target reference.
  • bounds: min/max/current/desired replica data plus generation info.
  • metrics: normalized configured/current metric rows.
  • reasons: raw condition-backed evidence, preserving Kubernetes condition type/reason/message where available.
• Added shared fixtures in testdata/hpa-diagnosis/cases.json covering maxed, metrics unavailable, partial metrics missing, unable to scale, disabled, pinned, scaling, stale, min-limited, stabilized, stable, and “at max without controller limit condition.”

Signal Policy

• “Maxed” now requires the HPA controller’s explicit ScalingLimited=True / TooManyReplicas evidence.
• An HPA merely sitting at current == desired == maxReplicas is treated as normal unless the controller says it wanted more replicas and was capped.
• ScalingActive=False is classified as metrics_unavailable unless it is the intentional zero-replica ScalingDisabled case.
• AbleToScale=False is classified separately as unable_to_scale.
• Partial metric gaps, min bounds, stale observed generation, pinned min=max, disabled zero-replica targets, and scale-down stabilization are kept as drawer/detail context rather than dashboard issue spam.

Backend Surfaces

• Resource detail responses now include hpaDiagnosis for HPA resources.
• Resource context includes an HPA summary so MCP/AI workflows can reason about autoscaler state without fetching raw YAML first.
• AI summary output uses the shared analyzer for HPA issue text.
• Dashboard/problem detection now delegates HPA state decisions to the shared analyzer instead of maintaining separate HPA heuristics.
• Topology resource wrapper types were extended to carry HPA diagnosis through existing resource detail response paths.

Frontend / UX

• The shared HPA renderer now has a Diagnosis section showing:
  • primary diagnosis summary,
  • state badge,
  • replica bounds,
  • raw reason/evidence rows,
  • normalized metric rows.
• The HPA Metrics section prefers backend diagnosis metrics when present and falls back to existing raw status metrics otherwise.
• Workload details now show compact autoscaler context when the workload is controlled by an HPA.
• Manual replica scaling is disabled for workloads whose replicas are controlled by HPA/KEDA, with the UI pointing the user toward the controlling scaler instead.
• The HPA list/table classifier remains intentionally conservative and fixture-backed so broad list views do not become noisy.

Shared UI / Types

• Added shared HPA diagnosis TypeScript types to @skyhook-io/k8s-ui.
• Added resource-utils-hpa for table-state classification, label/tone mapping, and status badge generation.
• Wired the HPA renderer through the existing renderer override path so Radar’s app can inject Prometheus charts while the shared renderer stays host-agnostic.

Reviewer Focus

• The main correctness question is the HPA state policy in pkg/hpadiag: whether each condition/state maps to the right Radar severity and surface.
• The main product question is whether list/dashboard signals are conservative enough. This PR intentionally does not promote metrics_incomplete, limited_min, stale, or stabilized into table warnings.
• The main UI question is whether the drawer gives enough evidence to act without exposing raw Kubernetes condition text as the primary summary.
• The main API question is whether adding optional hpaDiagnosis to resource detail responses is the right shape for Radar app consumers.

Testing

• go test github.com/skyhook-io/radar/pkg/hpadiag github.com/skyhook-io/radar/internal/k8s github.com/skyhook-io/radar/pkg/ai/context github.com/skyhook-io/radar/pkg/resourcecontext github.com/skyhook-io/radar/internal/server
• npm test --workspace @skyhook-io/k8s-ui -- resource-utils-hpa.test.ts WorkloadRenderer.test.tsx ResourceRendererDispatch.test.tsx
• make tsc
• make test

Visual-test: ran against kind-radar-gitops-demo with live HPA fixtures covering the HPA list, maxed drawer, metrics-unavailable drawer, and workload HPA context.

Notes / Tradeoffs

• This does not add live Prometheus metric diagnosis beyond the existing HPA charts. The diagnosis is based on Kubernetes HPA spec/status/conditions.
• Metric row normalization is best-effort across resource, container resource, pods, object, and external metrics.
• The table and drawer intentionally do not use identical state visibility. The drawer is the complete diagnosis surface; the table is for scan-worthy operational signal.