[roylibman]

After an upgrade, Radar gives no sign of what changed. New features only get found by accident. This PR adds a What's New dialog that opens once, the first time Radar starts on a version that has release notes. It can be reopened from a "What's new" link next to the Radar version on Home.

This PR ships dormant. The release-notes catalog (web/src/components/whats-new/releaseNotes.ts) is empty, so no version shows the dialog or the Home link until its release PR adds an entry. Draft notes for the next release are kept on a separate branch, to be finalized with the release tag.

Behavior

• Opens once per upgrade. The version is saved when the dialog is closed, so it doesn't open again for that version.
• Fresh installs don't see it. They only record the version. Installs that predate this feature are recognized by any radar* browser-storage entry. That check runs when the module loads, because the version check writes its own radar-update-check key during the first session. Checking later would make every fresh install look like an upgrade.
• Storage unavailable: no auto-open.
• Home: local installs now show "Radar vX" on Home (before, only in-cluster installs did), plus the link when notes exist for the running version. In-cluster upgrade guidance is unchanged and stays in-cluster only.
• Hidden in cloud mode and when embedded (Radar Hub).

DialogPortal accessibility (affects every dialog)

DialogPortal in @skyhook-io/k8s-ui focused the panel in an effect keyed on open, but the panel mounts one render later, so focus stayed behind the backdrop. This PR:

• moves focus into the dialog;
• traps Tab inside it, leaving alone any Tab an editor already handled (Monaco indent);
• restores focus to the element that opened it, at logical close;
• adds optional ariaLabelledBy / ariaLabel props.

ConfirmDialog and the What's New dialog are now named by their titles. The props are backward compatible. Radar Hub picks this up with its next k8s-ui bump. There are 10 new tests, 7 of which fail against the old component.

Verification

• make tsc passes. Web tests: 1518 pass. k8s-ui tests: 3923 pass.
• Checked live against a kind cluster, with a VERSION=v1.15.0 build and the draft notes:
  • A fresh profile stays closed, and Home shows "Radar v1.15.0 · What's new".
  • An upgrade from v1.14.1 opens once with "Updated from v1.14.1". Focus lands inside the dialog, which is named by its title.
  • Tab wraps from the last button to the first. Esc dismisses it, and it stays dismissed.
  • The Home link opens the dialog, and Esc returns focus to the link.

🤖 Generated with Claude Code

---

Note

Medium Risk
DialogPortal focus/trap/restore behavior changes every modal in k8s-ui (backward-compatible props, but altered keyboard/focus semantics); What's New is low-impact while the catalog is empty.

Overview
Adds a What's New release-notes dialog that auto-opens once after upgrading to a version with catalog entries (ships dormant with an empty RELEASE_NOTES until a release PR fills it). Dismissal and prior-version detection use localStorage; fresh installs only record the version; cloud and embedded hosts skip it. Users can reopen via a What's new link on Home (when notes exist), ?whats-new preview URLs, or a radar:show-whats-new window event. Home now shows the Radar version line for non-cloud local installs, with optional upgrade UI gated by showUpgrade.

DialogPortal gains modal accessibility: focus moves into the panel after mount (respecting autoFocus children), Tab cycles within the dialog without fighting editors that preventDefault on Tab, focus restores to the opener at logical close (with StrictMode-safe microtask handling), inert / pointer-events during exit animation, and optional ariaLabelledBy / ariaLabel. ConfirmDialog wires title id and close button label. New unit tests cover dialog focus, naming, and What's New eligibility logic.

^{Reviewed by Cursor Bugbot for commit 0b6cd3f. Bugbot is set up for automated code reviews on this repo. Configure here.}

[qodo-free-for-open-source-projects]

PR Summary by Qodo

Show What's New after Radar upgrades

✨ Enhancement 🧪 Tests 🕐 20-40 Minutes

AI Description

• Shows versioned release highlights once after eligible Radar upgrades.
• Excludes fresh, cloud, embedded, and storage-unavailable sessions from automatic opening.
• Adds Home and query-parameter entry points for reopening or previewing notes.

Diagram

graph TD
  A["App start"] --> B{"Eligible deployment?"} -- "Yes" --> C{"Release notes?"} -- "Yes" --> D{"Prior upgrade?"}
  D -- "Yes" --> E["What's New dialog"] --> F["Seen version"]
  D -- "Fresh install" --> F
  G["Home version link"] --> E
  H["Preview query"] --> E

Loading

High-Level Assessment

The following are alternative approaches to this PR:

1. Fetch release notes remotely

• ➕ Allows release content corrections without rebuilding Radar
• ➕ Keeps release copy outside the application bundle
• ➖ Adds network availability, caching, and trust concerns
• ➖ Could return notes that do not match the running binary
• ➖ Complicates offline and in-cluster installations

2. Use a React dialog context

• ➕ Avoids a global browser custom event
• ➕ Provides typed open and close actions to nested components
• ➖ Introduces provider and consumer wiring for one manual trigger
• ➖ Couples Home rendering more directly to dialog state

Recommendation: Keep the PR's bundled, version-keyed notes and local-storage persistence because the feature must work reliably in local and in-cluster environments without backend support. The custom event is proportionate for the single Home-to-App trigger; a context would become preferable only if more components need programmatic control. Replace the placeholder v1.15.0 content before release.

Files changed (7) +422 / -5

Enhancement (5) +379 / -5

App.tsxMount and expose the What's New dialog +3/-0

Mount and expose the What's New dialog

• Mounts the dialog outside embedded mode and passes application navigation into it. Wires Home's manual-open callback through a window event while leaving embedded hosts unaffected.

web/src/App.tsx

HomeView.tsxExpose release notes from the Home version line +8/-2

Expose release notes from the Home version line

• Checks whether notes exist for the running version before enabling the Home link. Shows the version line for eligible local installs while retaining upgrade guidance only for in-cluster deployments.

web/src/components/home/HomeView.tsx

RadarVersionLine.tsxAdd a What's New action beside the Radar version +28/-3

Add a What's New action beside the Radar version

• Adds an optional release-notes button to both current and outdated version displays. Introduces a separate flag for suppressing in-cluster upgrade guidance in locally managed installations.

web/src/components/home/RadarVersionLine.tsx

WhatsNew.tsxImplement the version-aware What's New dialog +246/-0

Implement the version-aware What's New dialog

• Adds automatic one-time opening based on versioned notes, prior Radar state, deployment mode, and storage availability. Supports Home events and query previews, persists dismissal state, and renders navigable release highlights.

web/src/components/whats-new/WhatsNew.tsx

releaseNotes.tsDefine versioned release-note content +94/-0

Define versioned release-note content

• Introduces typed release highlights and improvements with in-app destinations and an external release URL. Includes placeholder v1.15.0 notes and normalized version lookup for replacement at release time.

web/src/components/whats-new/releaseNotes.ts

Tests (2) +43 / -0

RadarVersionLine.test.tsxTest What's New and upgrade-link visibility +14/-0

Test What's New and upgrade-link visibility

• Verifies that the manual release-notes link requires a host callback and remains available independently of upgrade guidance.

web/src/components/home/RadarVersionLine.test.tsx

WhatsNew.test.tsTest upgrade and fresh-install display rules +29/-0

Test upgrade and fresh-install display rules

• Covers one-time upgrade display, normalized version matching, legacy-install detection, fresh-install suppression, and versions without notes.

web/src/components/whats-new/WhatsNew.test.ts

[qodo-free-for-open-source-projects]

Code Review by Qodo

🐞 Bugs (0) 📘 Rule violations (0) 📎 Requirement gaps (0) 🎨 UX issues (0) 🔗 Cross-repo conflicts (0) 📜 Skill insights (0)

1. The mock note records branch history ✓ Resolved 📘 Rule violation ⚙ Maintainability

Description

RELEASE_NOTES is preceded by a comment saying its content was merged on main since v1.14.1,
which records branch and release history in source. When the placeholder notes are replaced or the
branch advances, later readers must determine whether that historical provenance still describes the
data.

Code

web/src/components/whats-new/releaseNotes.ts[21]

+// Mocked from what is merged on main since v1.14.1 and not yet released.

Evidence

Compliance rule 3036538 prohibits code comments that describe diff or change history. The newly
added comment explicitly derives the mock content from changes merged on main since a named prior
release.

Rule 3036538: Disallow references to tickets or PR history in code comments
web/src/components/whats-new/releaseNotes.ts[21-21]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The comment above `RELEASE_NOTES` records branch and release history by describing what has merged since a prior version.
## Fix Focus Areas
- web/src/components/whats-new/releaseNotes.ts[21-21]
## Recommended Fix
Remove the comment, or replace it with a timeless explanation that the entries are placeholder release-note content and must be finalized before release without referring to branch history.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

2. Local users lose the Radar version line ✓ Resolved 🐞 Bug ≡ Correctness

Description

HomeView makes the entire radarVersion slot for local mode conditional on hasWhatsNew, which
is false unless the exact running version has a release-note entry. Any local release omitted from
the sparse notes catalog therefore loses the version display as well as the intentionally
unavailable link, while in-cluster releases keep displaying it.

Code

web/src/components/home/HomeView.tsx[145]

+          radarVersion={versionInfo && (deploymentMode === 'in-cluster' || (deploymentMode === 'local' && hasWhatsNew)) ? (

Evidence

hasWhatsNew requires both a host callback and an exact release-note match, and the new local-mode
branch uses that value to gate the whole version slot. Since releaseNotesFor returns a value only
for catalogued versions, local releases without an entry cannot display their version.

web/src/components/home/HomeView.tsx[78-81]
web/src/components/home/HomeView.tsx[142-153]
web/src/components/whats-new/releaseNotes.ts[90-94]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
Local installs render the Radar version line only when release notes exist for the exact running version, although only the What's New link should depend on notes.
## Fix Focus Areas
- web/src/components/home/HomeView.tsx[145-153]
## Recommended Fix
Render `RadarVersionLine` whenever `versionInfo` is available in local or in-cluster mode. Continue passing `onShowWhatsNew` only when `hasWhatsNew` is true, and preserve in-cluster-only upgrade guidance.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

3. The investigations button returns home ✓ Resolved 🐞 Bug ≡ Correctness

Description

releaseNotes always exposes /investigations, without consulting the agent eligibility that
controls whether that workspace can remain open. When the agents endpoint resolves with `eligible:
false, DiagnoseContext immediately replaces that route with /`, so clicking the highlight merely
closes the dialog and returns affected users home.

Code

web/src/components/whats-new/releaseNotes.ts[R72-73]

+        path: '/investigations',
+        cta: 'Open Investigations',

Evidence

The highlight's button passes /investigations directly to application navigation. The
investigations provider defines eligible: false as a run mode where the feature is unavailable,
and its URL synchronization effect closes the workspace and replaces every investigations route with
/ once that state resolves.

web/src/components/whats-new/releaseNotes.ts[68-73]
web/src/components/whats-new/WhatsNew.tsx[197-205]
web/src/api/diagnose.ts[24-33]
web/src/components/diagnose/DiagnoseContext.tsx[751-781]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The Investigations highlight always provides a navigation action even in run modes where the investigations workspace is explicitly unavailable and redirects back home.
## Fix Focus Areas
- web/src/components/whats-new/releaseNotes.ts[68-73]
- web/src/components/whats-new/WhatsNew.tsx[187-206]
- web/src/components/diagnose/DiagnoseContext.tsx[751-781]
## Recommended Fix
Expose investigation eligibility to the dialog and render the Investigations CTA only after eligibility resolves true. For ineligible environments, omit the action or replace it with an applicable setup or documentation destination rather than navigating to `/investigations`.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

Tip of the day

💡 Did you know, you can choose which labels appear on a finding, and whether they show icons or text

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗

[nadaverell]

Split into #1901 (DialogPortal accessibility, k8s-ui only) and #1902 (What's New dialog + Home version line). Each merges independently.