The hook’s effect is guarded by initRef and only runs once. This breaks expected behavior when enabled or autoRefreshMs change after mount (e.g., the existing test case “resets state when disabled”), and it can leave the refresh interval running even after enabled becomes false.

Consider restoring an effect that reacts to enabled/refreshMs changes (clearing any existing interval and resetting state on disable), while still keeping fetchData stable via refs/useCallback if needed.

insightsKey is derived only from heuristicInsights.length, so the enrichment request won’t re-trigger when the insights change but the length stays the same (e.g., rerendering with a different single insight). This breaks the debounce/reset behavior verified in useInsightEnrichment.test.ts (rapid updates test) and can leave enrichments stale.

Use a stable content-based key instead (e.g., hash/join of insight IDs + lastUpdated/severity), or keep the array in deps and stabilize upstream.

The periodic update effect is now useEffect(..., []) but reads stackServers from closure. If selectedStack, isDemoMode, or prometheusMetrics change, stackServers changes, but servers will keep updating from the initial stackServers only, leaving the card stale.

Include stackServers (or a stable key derived from it) in the dependency array, or store stackServers in a ref that the interval callback reads.

The metrics polling effect was changed to useEffect(..., []), but updateMetrics uses dynamicNodes, nodePodMap, and prometheusMetrics. With an empty dep array, the interval callback will keep using the initial values and won’t reflect topology changes or new Prometheus data.

Consider including a stable deps key (e.g., dynamicNodesKey, nodePodMapKey, and prometheusMetricsKey) or reading the latest values from refs inside updateMetrics instead of suppressing exhaustive-deps.

DashboardCustomizerProps includes onExport, but the component never destructures or uses it, so the export action passed from Dashboard.tsx is currently unreachable from Console Studio. There’s also a DashboardSettingsSection component added in this PR, but it isn’t wired into the Studio nav.

Either add a Settings/Export section (and nav item) that uses onExport/onReset, or remove the prop to avoid a false API surface.

Many user-facing strings in this updated SidebarCustomizer are now hard-coded (e.g., “No changes needed — …”, “Applied X changes”, “Reset Sidebar”, placeholders/titles). This bypasses the existing i18n approach used elsewhere in the component (t('sidebar.customizer.*')) and makes localization inconsistent.

Prefer adding translation keys and using t(...) for these strings; also avoid redeclaring AUTO_DISMISS_MS inside the else-branch since a module-level constant already exists.

The Console Studio nav labels are hard-coded English strings. Since the app uses i18next (and this PR adds dashboard.studio.* locale keys), these labels should be sourced from translations to keep localization consistent.

Consider storing translation keys (not labels) in CUSTOMIZER_NAV and resolving them with t(...) in the sidebar component.

This section introduces several new user-facing strings as literals (e.g., helper text, placeholders, button labels like “AI Suggest”/“Thinking…”, “Try:”, “Clear & show all cards”). Given the existing i18n usage (t(...)) and the new dashboard.studio locale entries, these should be translated to avoid regressions for non-English locales.

Consider replacing these literals with t(...) keys (with sensible defaults) and/or moving them into common.json.

When using “Add” for a collection, template cards are converted to CardSuggestion with title: c.card_type and description: ''. In Dashboard.tsx, handleAddCards uses s.title as the card title, so these cards will show raw type IDs instead of the template’s intended tc.title (and lose descriptions).

Consider passing through c.title (or a formatted title) and description when building the suggestions.